A Web service is programmable application logic accessible using standard Internet protocols. Publish-subscribe (“pub-sub”) Web service systems provide mechanisms for a Web service to register interest in receiving messages when events occur in other services and applications. For instance, messages generated by publishers may be forwarded to a central messaging hub or broker that in turn sends these messages to subscribers that have previously subscribed to receive some or all of these messages. A “subscriber” may send a request message indicating interest, or “subscription”, to an “event source” (another Web service) regarding notifications about certain events (e.g., current stock quotes, etc.). The request indicates that such event notifications are to be sent by the event source to an “event sink.” In a simplest scenario, the subscriber is the event sink. In another scenario, the subscriber is a third party independent from the event sink that manages the subscription for the event sink.
A subscriber may want to include context, cookies, or other non-standard data within each event notification sent by an event source to an event sink as part of a subscription. For purposes of discussion, such non-standard data is hereinafter often collectively referred to as “context”. Such context, for example, may be used by the event sink and/or an intermediary (a gateway, firewall, etc.) to configure operations, to transmit state or other data to the subscriber, etc. For instance, a security intermediary may use context included with an event notification to discard notifications that do not include an appropriate authorization token (context); a logging intermediary may use the non-standard data to log events that are part of a business relationship, and so on.
Unfortunately, a subscription request message from a subscriber to an event source is not designed to encapsulate such context. In particular, a subscription request is designed to encapsulate only a minimal amount of information—typically a 128-bit GUID or a Universal Resource Identifier (URI) address (network or logical) of an event sink. Accordingly, to include context within a subscription request, a subscriber typically modifies the request in a proprietary manner to add any context with the message. This means that components in a pub-sub system that desire to transmit context to another entity must share a common set of assumptions with at least that entity about how context in a subscription and/or event notification message is to be parsed, and subsequently interpreted. When an event source sends the context to the entity, for instance, with an event notification, the event source must at a minimum be able to decode the additional information present in the subscription. Instructions to implement such decoding of context information may have been provided via a document, a phone call, a piece of code sent to an event source developer, etc. Additionally, every time the subscriber wants to change the amount or the format of the additional data (context) it is likely that the event source will need to change as well to decode this new style.
For example, a subscriber may serialize context within the GUID or URI address of the event sink. Alternatively, the subscriber may add a data field to the structure of the subscription request to hold the context. Regardless of the manner in which the context is inserted into the subscription request, there must be tight coupling between the subscriber and the event source to extract, parse, and maintain such context. Additionally, serialization of context within a 128-bit GUID or URI substantially limits the format and quantity of the context being conveyed.
Intermediaries may have differing context requirements, such as authentication criteria. Additionally, certain context may need to be hidden from some recipients. This is because all intermediaries that receive context during normal communication flow of an event notification to an event sink may not be within a same trust domain. That is, one intermediary may not have authorization to access to context of another intermediary. These additional requirements result in even tighter coupling requirements between pub-sub components. Such tight coupling between pub-sub components is undesirable because respective components are generally more expensive and time consuming to create and maintain. Moreover, since context extraction for forwarding with event notifications is performed based on event source implementations, the subscriber has little, if any, control over the information sent to intermediaries and event sinks once the information has been sent to the event source.